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Notice 


This newsletter may contain information covered by one or more licenses, 
copyrights, and non-disclosure agreements. Permission to copy without fee 
all or part of this material is granted only to Institutional Members of 
the Usenix Association provided that copies are made for internal use at 
the member campus or plant site, 


* UNIX is a trademark of Bell Laboratories 


Guidelines for Submission of Newsletter Material 


I would like to use the modern text preparation and communications 
facilities of UNIX to as great an extent as feasible in the preparation of 
the Newsletter. I have established an account on our PWB/UNIX system so 
that those who can provide us with machine manageable material can do so. 
The telephone number is (512) &74-5511. The login name is login and the 
password is usenix. (The system is also host utexas-11 on the ARPANET. ) 


For those submitting paper copy of material, please produce your copy 
on a daisy wheel printer or similar high quality printing device. Line 
printer produced copy is typically not adequate for reproduction. Copy 
should be on 8 1/2" by 11" paper with a 1" margin on left, right, and bot- 
tom and 1 1/2" margin on top. 


U. S. Mail submissions should be addressed to: 


Login Newsletter 
Computation Center 

The University of Texas 
Austin, Tx 78712 


Attn: Wally Wedel 
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Editorial 


This issue of the newsletter carries two articles describing two of 
the "UNIX-like" systems available for micro-processor based computer sys— 
tems. These articles were developed from material supplied by the vendors 
and from conversations with representatives of the vendor. 


The emergence of these systems and others sure to follow raise some 
interesting and potentially disturbing questions. One such question is: 


What do we mean by the term "UNIX-like"? 


There seem to me to be three fairly distinct levels from which "UNIX- 
likeness" can be described. The first of these is the operating system 
command and response language (OSCRL) level (UNIX users read "shell"). The 
second level is the available utilities for the system under discussion. 
The third level is the program interface to the operatirg system (system 
calls). 


Level one defines a major portion of the user's view of the system. 
This level includes shell program statements, i/o redirection, and notation 
for specifying concurrent processing with interprocess communication. 


Level two describes products available under the system. Is there a 
familiar editor? What languages are available? Does the system provide 
text processing facilities comparable to those of UNIX? Are the utilities 
known by the same name as under UNIX? Do the utilities which carry the 
Same name as under UNIX work’ the same way? Are the parameters of the util- 
ities comparable to those of UNIX? 


Level three describes the program level interface. It assumes the 
existence of a reasonable high level programming language such as C or Pas— 
cal. Major questions here include 1) Do system calls named the same as 
those for UNIX behave the same way? 2) Are there additional calls to the 
system? 


UNIX or a look-alike? 


As many of us in the UNIX community know, the UNIX Programmer's Manual 
often does not cover fine points of the behavior of programs which run 
under UNIX. Systems which carry over most of the source code of the UNIX 
kernel and its utilities would seem to have the best chance of looking to 
users like a real UNIX. Those systems written from scratch to the specifi- 
cations of the UNIX Programmer's Manual would seem to stand a gocd chance 
of not working "right" to an experienced UNIX user unles: the code was 
developed by an experienced UNIX user. 


Current UNIX licensing procedures make it difficult to easily distin- 
guish between systems based on a high percentage of UNIX Bell Labs and sys- 
tems developed from the UNIX Programmer's Manual. 
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Cromemco's CROMIX operating system 


It is an interesting commentary on Cromemco's view of their industry that 
when the time came for them to consider a multi-user operating system for 
their line of micro-computers they turned to the UNIX model. The system 
they have developed should be easy for a UNIX user to learn to use. The 
shell command level lacks a pipe operator but otherwise looks a lot like a 
real shell. Many of the major UNIX functional capabilities are available 
under CROMIX but often with different names because they perform dif- 
ferently. The ‘System call xevel appears to be well d2fined with most of 
the necessary UNIX-like functions. A compatiblity module for their single 
user system, CDOS, is provided under CROMIX, 


A major incompatability between the current version of CROMIX and UNIX is 
the lack of an interprocess communications facility (pipes). Rumor has it 
that this omission will be corrected shortly. 


CROMIX uses the Z80. bank switching capability to allocate memory. 
Currently each process is allocated a 64k byte bank of memory with CROMIX 
itself occupying bank 0. Consequently, the minimum amount of memory 
required for a single process system is two banks or 128k bytes. This is a 
potential confining feature of CROMIX for many UNIX users who often gen- 
erate multiple processes without even being aware of it. Since many 
processes do not occupy anywhere near 64k bytes it would appear that a 
scheme for permitting multiple processes to reside in a single bank of 
memory would be desirable as a future enhancement if it could be obtained 
at relatively low cost. 


The CROMIX file system structure will appear very familiar to UNIX 
users. The file and directory naming conventions will also be recognizable 
by veteran UNIX users. The ASCII caret (7) has been introduced to refer to 
the ancestor directory of the current directory. (i.e. instead of ../file 
you say “file to reference a file in the parent directory). 


File protections have been modified slightly to include an append only mode 
in addition to the other file access modes of UNIX. 


Utilities 


Since no CROMIX Users Manual has been made available to me, no assessment 
of the available shell commands can be presented here. 


System Calls 


An important aspect of the UNIX-like property of an operating system is the 
nature of modifications to programs written for UNIX so that they will run 
on the target system. CROMIX actually does quite well in this regard. The 
designers have taken care to make sure that the names of system calls are 
changed where a system call is not compatible with UNIX. Most of the 
important system calls appear to be available in UNIX form or in an 
extended form. The pipe calls are an obvious omission. 
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Implementation 


CROMEMCO took the interesting approach of doing the operating system in 
assembler and then developing a C compiler. It is to be hoped that subse- 
quent implementations can be done with CROMEMCO C. Whether that ever comes 
about depends to a great extent on the quality of the code produced by 
their C compiler. 


CROMIX System Functions 


close(fn) - Close a file. 

creat(fname, pmode) - Create a file. 

lseek(fn, offset, origin) - Position file pointer. 

open(fname, rwmode) - Open a file. 

read(fn, buf, n) — Read from a file. 

write(fn, buf, n) ~ Write to a file. 

ecdos(z80regs) - Execute CDOS system call. 

ecromix(SYSCALL, z80regs) ~ Execute CROMIX system call. 

exit(status) -— Abort program. 

system(string) - Fork a shell and execute string. 

eaccess(channel) ~ Test channel access. 

echstat(channel, statustype, statusvalue, statusmask) - Change channel access 
privileges, 

chdup(channel) = Duplicates a channel. 

chkdev(dtype, dmumber) - Checks for the presence of a device driver. 
elink(channel, pathname) - Establishes a link to an open file. 

elose(fn) — Close a file. 

create(filename, accessmode, accessmask) - Creates and opens a new file. 
estat(channel, statustype, inodebuffer) - Determine status of open file. 
delete(filename) - Delete a file. 

error(errno, channel) - Display error message. 

exec(argv, pathname) — Executes a program. 

exit(status) - Abort a program. 

faccess(pathname) ~ Tests file access. 

fchstat(pathname, statustype, Statusvalue, statusmask) - Change status of file. 
fexec(chmask, argv, pathname) - Forks and executes a program. 
flink(pathname, newpathname) - Establishes a link to a file. 
fshell(argv) — Forks a shell process. 

fstat(pathname, statustype, inodebuffer) - Determine file status. 
getdate(date) - Gets the date. 

getdir(buffer) - Get pathname of current directory. 

getgroup(idtype) - Gets the group id. 

getmode(channel, modenumber) ~ Gets the characteristics of a console device, 
getpos(channel) - Get value of file pointer. 

getproc() — Get the process id. 

gettime(time) — Gets the time. 

getuser(idtype) - Gets the user id. 

indirect -— Identical to ccromix. 

makdev(pathname) - Create a new name for device. 

makdir(pathname) - Create a new directory. 

mount(dummypath, devpath, access) - Enables access to a file system. 


December 1980 5 login: 


UniFLEX Operating System 


The UniFLEX* Operating System is a state of the art operating system for 
microcomputers. The system's design has been influenced primarily by two 
other operating systems, FLEX and UNIX. UniFLEX retains the flexibility 
and ease of use of FLEX while incorporating some of the widely accepted 
structures of UNIX. 


UniFLEX is a true multi-tasking, multi-user operating system. Each user 
communicates with the system through a terminal and may execute any of the 
available system programs. 


Each user must 'log in! before being permitted to use the system. Tne log 
in process requires the user to enter his user name, followed by a pass— 
word. ‘The system checks the validity of the password, and if accepted, the 
system command language program is run. Full system accounting is sup- 
ported by UniFLEX which will keep track of user log-in and log-out times, 
as well as the user's utilization of system resources. 


UniFLEX is a very complete operating system and has no practical limita- 
tions built into the software, almost all of them are hardware imposed. It 
supports a hierarchical file system allowing file sizes up to one billion 
bytes and disk capacities of over eight billion bytes. All files are fully 
protected. A user may read, write, or execute protect files on an indivi- 
dual basis. All system I/O is device independent since I/O devices may be 
attached to the system. A sample system configuration might have a ninety 
megabyte disk, a thirty megabyte disk, two eight inch floppies, a parallel 
driven printer, and nine user terminals. Any running task may initiate 
another task in an asynchronous manner. Inter-task communication is also 
supported. Task swapping may take place on those systems incorporating an 
appropriate swapping device. In real time applications, where swapping may 
be detrimental, it is possible to lock a task in main memory. The user's 
main connection with the system is through the command language, the shell. 
This is the vehicle for inputting commands to the system. It supports a 
wide variety of features including parameter passing and various types of 
name pattern matching. Input to the command language may be from the ter- 
minal or from any file (including other devices). 


The overall design of UniFLEX is geared toward the larger microcomputer 
systems. UniFLEX will be for the upcoming generation of microcomputers 
which support massive amounts of main and secondary memory. Not only is 
the 6809 supported with this system, but support of future 68000 based 
machines will be supported. 


Hardware Requirements 


UniFLEX requires a system based on either the 6809 or 68000. The mainframe 
must support extended addressing (a minimum of 19 address lines) and some 
form of memory segment management. The memory mapper must have the minimum 
must have the minimum ability of mapping memory segments no larger than 4K, 
anywhere in the cpu address space. The operating system will support 


* UniFLEX and FLEX are trademarks of Technical Systems Consultants, Inc. 
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multiple mapping registers as well as hardware memory protection schemes 
although neither 1s a requirement, A minimum of 96K of memory is required. 
The operating system code resides in less than 14K of memory, but in order 
to support all of the system's features, such as system accounting, 
automatic login, and multiple user tasks, the 96K is strongly recommended 
as a minimun. 


All system 1/0 devices must be interrupt driven. Terminals may be run 
either from separate ACIA type controllers or through an I/O buffer proces- 
sor, At least one eight inch, single density floppy disk drive capable of 
supporting 512 byte soft sectors must be supported. The drive must be 
interfaced with a DMA, interrupt producing controller. This drive will be 
used for program transportation and system booting. Any other disk con- 
trollers may be added to the system but they should be of the DMA variety 
and support 512 byte blocks. 


System Support 


The basic UniFLEX system includes the operating system, about 50 system 
utilities, a text editor, macro assembler, and system configuration pro- 
grams. Systems maintenance is available. 


There is currently a wide variety of support software available or in the 
development stages to run under UniFLEX. These include a C compiler, Pas- 
cal, Text Processing system, a debug package, and BASIC incremental com- 
piler which is compatible with out Extended BASIC. It should be noted that 
both the C and Pascal compilers will produce assembler language output 
which will yield much more efficient systems than others which produce an 
intermediate code (such as P-Code)} which must be interpreted. Many other 
programs are being considered, including FORTRAN, RPG/11, and a data base 
management system. 


Operating System Calls 
UniFLEX supports a wide variety of system calls. These deal with file 


management, task management, and general system maintenance. A partial 
list of calls will be given here along with a brief description of each. 
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UniFLEX System Calls 
File managing and i/o calls 


open(pathname,mode) - Open a file for read or write or both 
create(pathname,permission) - Create a new file and open it for write 
read(filenumber,address,count) ~ Read from a file 
write(frilenumber,address,count) - Write to a file 

seek(filenumber ,offset,type) — Position file pointer 
close(filenumber) ~ Close a file 

dup(filenumber) ~ Duplicate an open file 

dups(filenumber ,specifiednumber) - Duplicate a specified file 


chown (pathname ,newowner) ~ Change the file owner 
chprm(pathname,permission) - Change file access permission 
chace(pathname,permission) - Check file access permission 
defacc(permission) - Set default file access permission 


link(oldpathname,newpathname) — Link to an existing file 
unlink(pathname) - Unlink from a file (delete) 
maksd(pathname,permission,special) - Make a special directory type file 
chdir(pathname) - Change working directory 


ofstat(filenumber,buffer) -— Get an opened file's status 
status(pathname,buffer) - Get a file's status 


mount(devicepathname ,pathname,mode) ~ Mount a device on the system 
unmnt (devicepathname) ~ Unmount a device 


Tasks management calls 


exec(pathname,arglist) ~ Execute a new program 
fork() - For a new task 

wait() - Wait for a forked task to complete 
term(status) - Terminate a task 


epint(interruptnumber,address) — Catch a program interrupt 
spint(tasknumber,interruptnumber) - Send a program interrupt 


gtid() « Get the task id 

guid() - Get the user id 

suid(newuserid) ~ Set the user id 
setpr(priority) - Set running priority bias 


The Usenix Association 


PURPOSE: The Usenix Association is an organization of Western Elec- 
tric licensees and sub-licensees formed for the purpose of 
exchanging information and ideas about the UNIX operating 
system and the C Progamming Language. 


MEMBERSHIP: Four classes of membership in Usenix are offered: 


1. Institutional Membership. Institutional Members are 
the voting members of the Usenix Association. This 
class of membership is open only to licensees or  sub- 
licensees of Western Electric Co. 


2. Non=-voting Institutional Membership. This class of 
membership is open to corporate affiliates of AT&T. 


3. Individual Membership. Open to employees of class 1 
and 2 members and others who are bound by the software 
agreements with Western Electric and its licensees. 


- 4, Public Membership. Open to anyone with a bona fide 
interest in the purpose of the Usenix Association. 
For further information write: 


Usenix Association 
Rockefeller University 
Box 8 

1230 York Avenue 

New York, New York 10021 
(212) 360-1182 


Facts about UNIX and the Programming Language C 


The UNIX operating system was developed by Ken Thompson and Dennis Ritchie 
of Bell Laboratories in Murray Hill, N.H., during the early 1970's. The C 
Programming Language was developed originally by Thompson and Ritchie as 
the implementation language for UNIX. UNIX is made available to the public 
by Western Electric Co. through its patent licensing office in Greensboro, 
North Carolina, 


A fine overview of UNIX and C was published in the Bell System Technical 
Journal, Vol. 57, No.6; Part 2, in August 1978. The C Programming Language 
is described in the book The C Programming Language by Brian Kernighan and 
Dennis Ritchie published in 1978 by Prentice Hall. 


